In the development of a communication network, the communication network undergoes an evolution from a conventional circuit switched network to an Internet Protocol (IP) packet switched network with separated control and bearer mechanisms, and then to a full IP multimedia network.
Currently, the next generation network has completely started to use IP as a bearer. In the evolution towards a full IP network, the problem of end-to-end quality of service (QoS) needs to be considered, so as to provide services, especially real-time services satisfactory to customers. Since the IP network can provide more kinds of services such as multimedia call, file downloading, and webpage browsing, the network is required to be capable of detecting different service flows, making statistics of charging information such as traffic and duration, and reporting the charging information to a charging center. In order to solve relevant problems about QoS and flow-based charging, the 3rd Generation Partnership Project (3GPP) defines a PCC architecture, which enables the network to detect different service flows and realizes QoS control and makes charging statistics for various service flows.
FIG. 1 is a schematic view of a PCC architecture. As shown in FIG. 1, the PCC architecture mainly includes a policy control and charging rules function (PCRF), a policy and charging enforcement function (PCEF), a subscription profile repository (SPR), an application function (AF), an offline charging system (OFCS), and an online charging system (OCS).
The PCRF decides corresponding PCC rules according to a limitation of a user's access to a network, an operator's policy, user subscription data, information of a service currently used by the user (acquired from the AF), and so on, and provides the policy to the PCEF, so that the PCEF executes the PCC rules. The PCC rules include detection rules for a service data flow, that is, a collection of IP flows for accomplishing a certain service such as voice, whether to perform gating, QoS corresponding to the service data flow, flow-based charging rules, and so on.
The PCEF, located in a gateway (GW), is configured to execute PCC rules delivered or designated by the PCRF. Specifically, the PCEF performs the detection and measurement of a service data flow, ensures the QoS of the service data flow, user plane traffic processing, control plane session management triggering, and so on. The PCRF dynamically generates or modifies corresponding PCC rules according to session information from an application layer of the AF.
The PCRF and the PCEF are connected via a GX reference point. The GX reference point mainly realizes the following functions: establishing, maintaining, and terminating an IP connectivity access network (IP-CAN) session, enabling the PCEF to request PCC rules from the PCRF; enabling the PCRF to provide PCC rules to the PCEF; and negotiating a mode of establishing an IP-CAN bearer. The GX reference point uses a Diameter protocol defined by the Internet Engineering Task Force (IETF).
To make the process of the present invention more comprehensible, several terms are explained first.
The IP-CAN refers to an access network having a property of reserving IP service continuity, that is, keeping the service uninterrupted, when a user roams in an access network, that is, when the user changes his/her position in the access network, for example, a general packet radio service (GPRS) network, an interworking wireless local area network (I-WLAN) network, and so on.
The IP-CAN bearer refers to an IP transmission path having explicit rate, delay, and bit error ratio (BER), which is a path from an access network to a GW. For example, the IP-CAN bearer is corresponding to a packet data protocol (PDP) context in a GPRS network.
IP-CAN session refers to a connection relationship between a user equipment (UE) and a packet data network (PDN), for example, an internet network identifier (ID), which is identified by an IP address of the UE and an ID of the UE. As long as the UE is assigned with an IP address and can be identified by an IP network, an IP-CAN session exists. The IP-CAN session may include one or more IP-CAN bearers.
As known from a process of establishing an IP-CAN session and a process of establishing an IP-CAN bearer in the prior art, a binding relationship shown in FIG. 2 is formed on the PCEF/GW. FIG. 2 is a schematic view of a binding relationship among an IP-CAN session, IP-CAN bearers, PCC rules, and IP flows. As shown in FIG. 2, it is assumed that, in the establishment of the IP-CAN session, two IP-CAN bearers with different QoS requirements are established in the same IP-CAN session, so as to satisfy different QoS requirements, and each IP-CAN bearer may have a plurality of IP flows, for example, the user may download files from different servers at the same time. As shown in FIG. 2, an IP-CAN bearer 1 includes two IP flows, that is, IP flow 1 and IP flow 2, and an IP-CAN bearer 2 includes four IP flows, that is, IP flow 3 to IP flow 6.
When determining PCC rules in the prior art, the PCRF is required to send a credit control answer (CCA) message to the PCEF/GW and carry PCC rules in the CCA message. The specific message format is shown as follows (for the sake of simplicity, not all parameters are listed):
   <CC-Answer> ::= < Diameter Header: 272, PXY >         < Session-Id > (Session ID, corresponding toone IP-CAN session)         { Auth-Application-Id }         { Origin-Host }         { Origin-Realm }        *[ Event-Trigger ] (Event to be detected)      *[ Charging-Rule-Install ] (PCC rules to be executed,and an IP-CAN bearer ID is further included if the PCRF performsbearer binding)
As seen from the existing CCA message format, the event detection delivered by the PCRF to the PCEF/GW is directed to the entire IP-CAN session. The method in the prior art only performs event detection directed to the whole IP-CAN session, and thus causes the following defects.
In the actual application, the PCRF may need to detect a status of a corresponding IP flow in a certain IP-CAN bearer or a certain PCC rule, instead of a status of the whole IP-CAN session. However, in the prior art, the PCEF/GW may detect IP-CAN bearers or IP flows which the PCRF is not interested in and then report the detection status thereof, but the PCRF does not need such information. In this way, redundant message exchange definitely occurs between the PCRF and the PCEF/GW, so that unnecessary load is increased between the two equipments. For example, the PCRF is not interested in the situation of short-time interruption of file downloading via the IP-CAN Bearer 2 shown in FIG. 2, but in the existing method, the PCEF/GW also reports the interruption information if the IP-CAN Bearer 2 is interrupted.